\section{Discussion and Related Work}
\label{sec:RW}

\begin{table*}[t]

%\begin{tabularx}{p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm}}
\begin{tabularx}{\textwidth}{X X X X X X} % 6 columns

\toprule 


%{\bf } &  \alc{ {\bf FPL}} & \alc{{\bf PU}} & \alc{{\bf PP}} & \alc{{\bf SRC}}& \alc{{\bf OS}} & \alc{{\bf RS}} & \alc{{\bf PS}} & \alc{{\bf CR}} \\ 

 &  \alcx{\bf DM} &  \alc{\bf SM} & \alc{\bf CS} &\alc {\bf SC} & \alc{\bf CG} \\ 

\midrule 

{\bf SecureUML}\cite{Basin2006a}&\cc{UML}&\cc{Profiles}&\cc{OCL}&\cc{AC}&\yes\\
{\bf UMLsec}\cite{Jan2002} & \cc{UML}&\cc{Profiles}&\no&\cc{C,IF,AC}&\no\\
{\bf secureMDD}\cite{moebius_securemdd:_2009}& \cc{UML} & \cc{Profiles} &\no & \cc{AC}&\yes \\
{\bf ModelSec}\cite{sanchez_modelsec}& \cc{UML} & \cc{SecML}&\kinda & \cc{MC}&\yes\\
 {\bf SECTET}\cite{Breu2007a}& \cc{SE-UML} & \cc{Profiles}&\cc{SE-PL}&\cc{AC}&\kinda\\
{\bf S@R }& \cc{UML}&\cc{S@R} & \cc{S@R}&\cc{AC,OB}&\yes\\

\midrule
\multicolumn{6}{c}{AC: Access Control, C: Confidentiality, }\\
\multicolumn{6}{c}{ IF: Information Flow, OB: Obligations, MC: Multiple Concerns}\\

\midrule

\multicolumn{6}{c}{ {\bf DM}: System Modeling, {\bf SM}: Security Modeling, {\bf CL}: Contextual Security}\\

\multicolumn{6}{c}{  {\bf SC}: Security Concerns, {\bf CG}: Code Generation} \\
%\multicolumn{9}{c}{ }\\

\bottomrule 

%\textit{•}
\end{tabularx} 

\caption{Comparison of \SAR with Existing MDS approaches}
\label{table:stateOfTheArt}

\end{table*}



Since the seminal contributions of Lodderstedt and Basin with Secure\textsc{Uml} \cite{Lodderstedt2002}, and Jan with \textsc{Uml}Sec \cite{Jan2002} back in 2002, model-based development of secure systems has been a very active research area. In Table \ref{table:stateOfTheArt}, we compare several contributions with respect to several dimensions: system (DM) and security modeling (SM); contextual security (CS); security concerns (SC) (i.e. what kind of security properties can be expressed); and code generation (CG). The rest of the section contrasts these approaches with ours. %Since runtime policy updating and security rule violation monitoring is not, to the best of our knowledge, present in any of these approaches, we do not discuss this dimension.

\medskip\noindent
\textbf{Domain \& Security Modeling.}  \textsc{Uml} is by far the most represented way for domain security, as witnessed by the first column in Table~\ref{table:stateOfTheArt}. As already reminded, these approaches annotate the business \textsc{Uml} model with security requirements. Conceptually, our approach is different since we introduce the \SAR DSL to specify security requirements and their mapping to target systems. One advantage of our approach is that it cleanly separates security from system specification, as opposed to the use of \textsc{OCL} constraints for example to specify contextual policies when \textsc{Uml} is used with profiles. Therefore, our approach better satisfies the separation of concerns principle. 

\medskip\noindent
\textbf{Expressivity} of Security Languages is a crucial challenge for current \textsc{Mds} approach. We review this aspect with respect to several dimensions:
\begin{description}
	\item[\emph{Requirements.}] Many systems have security requirements way beyond only access control such as obligations, as Basin, Clavel and Egea already noticed \cite{Basin2011}. However, obligation requirements, necessary for the expression of several usage control and privacy policies  \cite{Barth2006,Barth2007,Elrakaiby2011,Mont2004a,Park2004}, and their monitoring is not covered by current \textsc{Mds} approaches. To the best of our knowledge, \SAR is the first \textsc{Dsl} that integrates both authorizations and obligations, with management and enforcement support using an \textsc{Mds} approach. There are however other security properties not covered by our approach (information flow, confidentiality) whereas confidentiality can be generally expressed using access control requirements and are \emph{de facto} supported. It remains to explore the possibility of enriching our \textsc{Dsl} to tackle other concerns. 
	
	\item[\emph{Contextual Security.}] If some approaches allow the specification of runtime conditions, security rules are usually expressed using a mix of \textsc{Uml} annotations and \textsc{Ocl}-based constraints. However, \textsc{Ocl} can only address limited runtime specifications: for example, expressing the fact that an instance field's value participates in a method call as an effective parameter is not an easy task. Contrasting with these approaches, we handle runtime conditions in a compartmented way: an abstracted representation of the runtime is maintained, and the security officer designs requirements using a pattern-like language for specifying contexts and operations participating in policy actions. The matching, at runtime, ensures a dynamic evaluation of the requirements. 
	
	\item[\emph{Security Concerns.}] Very few approaches can handle several security properties. With \textsc{Uml}Sec, Jan \cite{Jan2002} supports confidentiality, information flow and access control. ModelSec \cite{sanchez_modelsec} seems promising: the \textsc{Dsl} at the core of the language can easily be extended with new security concerns.
\end{description}


\medskip\noindent
\textbf{Violation Monitoring \& Policy Runtime Updating.} Runtime policy updating and security rule violation monitoring is not, to the best of our knowledge, present in any of the current approaches.  

\medskip\noindent
\textbf{Security Infrastructure.} Despite the use of \textsc{Mds} techniques, such as automated transformations, it is still difficult to enable full code generation from high-level requirements. Secure\textsc{Uml} \cite{Basin2006a} supports the generation of secure systems for two target architectures (Enterprise JavaBeans and Microsoft DotNet), but the generating mechanism relies on pre-existing security mechanisms. In \textsc{Sectet}, the information relevant for authorisations are specified using the tool's language, and transformed into \textsc{Xacml} specifications. In \cite{sanchez_modelsec}, security and business are composed into a model from which Java code is generated. In our approach, code generation and adaptation appears in two areas: first, the aspectJ layer monitoring the application is automatically tailored for the application on the basis of the static mappings to filter out information communicated to the PDP; and second, security policies are generated from the security model into Prolog, to compute policy decisions. The remainder of our security infrastructure such as aspects monitoring the application and the policy engine interpreting the security policy are application-independent.


